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Abstract 

Multi-level languages and Arrows both facilitate metaprogramming, 
the act of writing a program which generates a program. The arr 
function required of all Arrows turns arbitrary host language ex- 
pressions into guest language expressions; because of this, Arrows 
may be used for metaprogramming only when the guest language 
is a superset of the host language. This restriction is also present 
in multi-level languages which offer unlimited cross-level persis- 
tence. The converse restriction, that the host language is a subset 
of the guest language, is imposed for multi-stage languages - those 
multi-level languages with a run construct. 

This paper introduces generalized arrows and proves that they gener- 
alize Arrows in the following sense: every Arrow in a programming 
language arises from a generalized arrow with that language's term 
category as its codomain (Theorem |4.5.4[ >. Generalized arrows im- 
pose no containment relationship between the guest language and 
host language; they facilitate heterogeneous metaprogramming. The 
category having all generalized arrows as its morphisms and the 
category having all multi-level languages as its morphisms are iso- 
morphic categories (Theorem |4.7. 8 1. This is proven formally in 
Coq, and the proof is offered as justification for the assertion that 
multi-level languages are generalized arrows. 

Combined with the existence of a particular kind of retraction (Defi- 
nition [4~83) l in the host language, this proof can be used to define 
an invertible translation from two-level terms to one-level terms pa- 
rameterized by a generalized arrow instance. This is ergonomically 
significant: it lets guest language providers write generalized arrow 
instances while the users of those guest languages write multi-level 
terms. This is beneficial because implementing a generalized ar- 
row instance is easier than modifying a compiler, whereas writing 
two-level terms is easier than manipulating generalized arrow terms. 

Haskell is one example of a host language with the necessary kind 
of retraction. A modified version of GHC with multi-level terms is 
offeredjas a proof of concept; the Haskell extraction of the Coq 
proofs mentioned above has been compiled into this modified GHC, 
and is made available as a new flattening pass. 



informal way, giving an idea of the programmer's perspective 
and some sample code. Section[3]contains no theorems, proofs, 
or formal definitions and is not rigorous in any sense. 

• SectionEJdefines generalized arrows, multi-level languages, and 
their respective categories, and proves that these categories are 
isomorphic. All definitions and theorems in this section have 
been formalized in Coq. 

• SectionBldescribes a proof-of-concept implementation, instan- 
tiating the theorems of the previous section for an extension of 
System FC | SCJD07 post-publication Appendix C] and using 
the Haskell extraction of the resulting Coq proofs as part of a 
modified GHC. All of the examples from Section[3]are included 
as examples with the compiler. 

Section[6] summarizes the paper's results, highlights known deficien- 
cies, and mentions a few directions for future work. 



2. Related Work 

One of the earliest examples of language support for metaprogram- 
ming is the eval primitive, present from the earliest days of LISP. 
However, the eval primitive lacked access to the state of the current 
process; Smith | Smi83 1 remedied this, but did so via a definition 
which was self-referential in the sense that it used reflection to 
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1. Introduction 

The next section (Sectionpl surveys related work. The following 
three sections cover the same topics three times, each time from a 
different perspective: 

• Section [5] reviews Arrows, introduces generalized arrows, re- 
views multi-level languages, and previews the translation from 
the latter to the former. This is done by example, in a completely 
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n = if n== 
then 

else 




ga_drop 
ga_constant 1 
ga_copy 
ga_first id 
ga_second (pow' 
ga_mult 
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Figure 1. An example two-level program pow, which computes 
x n (top), its flattened representation as a generalized arrow term 
(bottom), and a diagrammatic visualization of the terms produced 
by each of the two branches of the if clause (center). Identifiers 
prefixed with "ga_" come from type classes described in Section |3~3"1 
The intuition behind the translation is explained in Figure [5] and 
SectionEJspecifies the translation in detail. 
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explain reflection. Wand later |Wan86| provided a non-circular ex- 
planation of this phenomenon. 

More recent research on metaprogramming, specifically multi-level 
programming in a typed setting, can be divided into intensional 
metaprogramming, which permits inspection of terms from a later 
level, and non-intensional metaprogramming, which does not. Al- 
though the former offers additional capabilities for decomposing 
code which has already been assembled, it requires sophisticated 
mechanisms for maintaining hygiene and ensuring that a-equivalent 
terms are truly indistinguishable. Most work in this area has dealt 
with languages that have an intrinsic notion of freshness and name 
exchange based on nominal logics, as in FreshML [SPG03|. The 
present paper deals only with non-intensional metaprogramming. Al- 
though non-intensional metaprogramming lacks the ability to inspect 
code terms, it does have a counterbalancing advantage: the com- 
piled implementation is free to perform "reduction under lambda" 
on later-stage terms, altering their syntactic structure. Because this 
syntactic structure cannot be examined by earlier stages, such reduc- 
tions are safe. Research in this area has clustered mainly around two 
approaches: level annotations and modal types. 

Level annotations were originally motivated by the annotations used 
for manual binding-time analysis; these annotations and their use 
for explicit staging were first codified in MetaML | TSOO | which was 
developed in quite a large number of subsequent papers, c ulminating 
in a full-featured implementation called MetaOCaml ICLG + 01I . 
A major advance was the introduction of environment classifiers 
by Taha and Nielsen [TN03 1. By careful use of these classifiers - 
type variables which are never instantiated except with other type 
variables - one can express, in the type system, the fact that a given 
term from a later stage has no free variables. This, in turn, can be 
used to ensure at compile time that the run operation is used safely. 
More recently, work has been done on inference for these classifiers 
ICMT04I . 

Modal types served as an early foundation for investigations into 
multi-level programming, beginning with the use of temporal logics 
by Davies and Pfenning [Dav96|, who note that "Moggi's compu- 
tational A-calculus only distinguishes values from computations 
and does not allow us to express stage separation." Along with 
Wickline and Lee |WLPD98|, they achieved an implementation ca- 
pable of runtime code generation [WLP98| and identified inlining 
as an operation which cannot be expressed via S4 types. This led to 
more sophisticated modal operators, such as that of Nanevski and 
Pfenning's v calculus |NP05|. Along with the metamathematics 
of contexts |BBM95|, this work suggests a path toward a unified 
account of environment classifiers as modal types. 

Most work on giving category-theoretic semantics to multi-level 
languages has been based on indexed categories. Jacobs |Jac91| 
appears to have been the first to advocate their use to represent 
contexts, creating a separate category for each possible context 
to the left of the turnstile. Indexed categories were also used by 
Moggi in the form of presheaves to investigate two-level languages 
|Mog97|. This work was later extended with Harper and Mitchell to 
explain the phase distinction in the ML module system |HMM96|. 

Kameyama, Kiselyov, and Shan | KKcS08 1 provide one translation 
from homogeneous multi-stage terms into single-stage terms. The 
resulting encoding uses cartesian tuples to represent contexts, which 
is workable so long as no substructural types are present in the 
language. Their work was particularly notable in that it directly 
addressed the influence of weak side effects such as nontermination 
and extrapolated to stronger side effects which might cause scope ex- 
trusion (for example, reference cells). More recently Choi, Aktemur, 
Yi, and Tatsuta have defined an "unstaging" translation [C AYTlll 
which can statically analyze homogeneous metaprograms. 



The development of Arrows began with the premonoidal categories 
of Power and Robinson | PR97 1 , which were introduced in order to 
represent contexts as objects in a category; the category Types(£) 
of this paper is based on the same idea. Power and Thielecke later 
examined the case where the center of such a category admits a 
strict monoidal identity-on-objects functor from a cartesian category 
|PT97|, later termed a Freyd Category. It was later proved that 
premonoidal categories which admit such a functors are in bijective 
correspondence with strong K-categories [LPT03 Definition 6.7], a 
refinement of Hasegawa's K-categories |Has95 1; these are the term 
categories of lambda calculi without first-class functions. Arrows 
first appeared in functional programming in the work of Hughes 
|HugOO|. Paterson's paper on Arrow notation discusses K-categories 
|Pat01 , Section 3.3] and suggests that his "command sublanguage 
could be viewed as a language for such indexed categories." 



Heunen and Jacobs |HJ06| along with Hasuo | JHI09] gave Arrows 
a definition in terms of large categories, viewing them as a monoid 
in the category of bifunctors Cat[C x C op , V] where C is V-enriched 
(along with a "strength"). More recently, Atkey [ Afk08| has exam- 
ined the important role of enrichment in the definition and use of 
Arrows. 



3. Introduction By Example 

3.1 Arrows in Haskell 

From a programmer's perspective, an Arrow is a type belonging to 
the type class below; the id and »> declarations come from the 
Category superclass: 

class Category a => Arrow a where 



id 


: a x x 


(»» 


: axy->ayz->axz 


arr 


: (x -> y) -> a x y 


first 


: a x y -> a (x,z) (y,z) 



Instances of this class must obey the laws of fPatOl. Figure 1]. 



3.2 BiArrows in Haskell 

BiArrows are mea nt to be Arro ws with a notion of inversion. They 
were introduced in lASvW + 05l and further examined in | JHI09 1 . A 
BiArrow is an instance of the following class: 

class Arrow b => BiArrow b where 
biarr : : (x->y) -> (y->x) -> b x y 
inv : : b x y -> b y x 

The BiArrow class adds a new constructor biarr, which is intended 
to be used in place of arr. It takes a pair of functions which are 
assumed to be mutually inverse. The inv function attempts to invert 
a BiArrow value. 

Types belonging to the class BiArrow consist of operations which 
might be invertible. Some BiArrow values are actually not invertible, 
so the inv operation is partial and may fail at runtime. Since the type 
of inv does not include any way of reporting such failures (e.g., an 
Either type or Error monad), the behavior in these circumstances 
is undefined and must appeal to mechanisms outside the semantics 
of the language (e.g., Prelude . error). The type system is not 
capable of ensuring that "well-typed programs cannot go wrong" 
|Mil78| in this wajrl Moreover, nothing stops a program from 

2 Note that aside from failures of inv there is a second, separate, issue: 
the user of a BiArrow might supply a pair of functions to biarr which 
are not in fact mutually inverse to each other. However, in this case the 
program will simply compute the wrong result rather than fail via some 
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class Category g 

—id 

— (»» 

ga_f irst 

ga_second 

ga_cancell 

ga_cancelr 

ga_uncancell 

ga_uncancelr 

ga_assoc 

ga_unassoc 



=> GArrow g (**) u where 
g x x 

gxy->gyz->gxz 

g x y -> g (x ** z) (y ** z) 

g x y -> g (z ** x) (z ** y) 

g (u**x) x 

g (x**u) x 

g x (u**x) 

g x (x**u) 

g ((x** y)**z ) ( x**(y **z)) 

g ( x**(y **z)) ((x** y)**z ) 



class GArrow g (**) u => GArrowCopy g (**) u where 
ga_copy : : g x (x**x) 

class GArrow g (**) u => GArrowDrop g (**) u where 
ga_drop : : g x u 

class GArrow g (**) u => GArrowSwap g (**) u where 
ga_swap : : g (x**y) (y**x) 

Figure 2. The definition for the (GArrow) type class and its 
three most frequently implemented subclasses. The class Category 
comes from the standard Control . Category module. 



passing a BiArrow and its class dictionary to a function whose 
type is Arrow a=> .... Such a function would have no reason to 
suspect that using arr rather than biarr in such a situation is 
dangerous! Not only can the use of BiArrows lead to undefined 
behavior, this behavior may be triggered by the composition of two 
programs which would each have been completely acceptable in 
isolation. 

Unfortunately there is no way to fix this within the framework 
of Arrows, because the Arrow type class requires that arr be 
defined for arbitrary functions - even those like f st = X(x, y).x 
which cannot possibly have an inverse. Not even the most powerful 
dependent type system can help with this problem: any restriction 
on the use of arr would result in an implementation which was no 
longer an Arrow. Moreover, the arr function is tightly woven into 
the laws which prescribe the behavior of Arrows, so solving the 
problem is not as simple as replacing arr with biarr. Finally, 
the desugaring algorithms for Arrow notation |Hug04, Section 
3.4][Tea09, Section 7.10] and the Arrow calculus lLWYlOl rely 
on unrestricted use of arr, so eliminating or restricting arr would 
mean forfeiting those comforts as well. 

Perhaps we might admit only certain special cases of arr. For 
example, we might require some value which behaves like (arr 
Xx.x), but not allow arbitrary functions (like f st) to be lifted. But 
what criteria should we use for deciding which special cases to 
require? It would seem unwise to make a choice based on any one 
particular application such invertible programming. Generalized 
arrows are the result of searching for a well-motivated collection of 
definitions to fill the void left by removing arr. 

3.3 Generalized Arrows in Haskell 

Section H] will define generalized arrows formally, in arbitrary 
languages. However, before presenting the abstract constructions, 
we will first survey one specific case: generalized arrows in Haskell, 
as embodied in the GArrow class shown in Figure[2] Like the Arrow 

extra-semantical error reporting mechanism. Preventing this sort of problem 
is possible only with a type system rich enough to express facts about 
equivalence of functions, which typically requires fairly powerful dependent 
types (such as Coq's). Generalized arrows do not address this second issue. 



instance Arrow 
ga_f irst 
ga_second 
ga_cancell 
ga_cancelr 
ga_uncancell 
ga_uncancelr 
ga_assoc 
ga_unassoc 



=> GArrow a (,) () where 
first 
second 

arr (\(0,x) -> x) 
arr (\(x,Q) -> x) 
arr (\x -> (0,x)) 
arr (\x -> (x,())) 
arr (\((x,y),z) -> (x,(y,z))) 
arr (\(x,(y,z)) -> ((x,y),z)) 



instance Arrow a => GArrowDrop a (,) () where 
ga_drop = arr (\x -> ()) 

instance Arrow a => GArrowCopy a (,) () where 
ga_copy = arr (\x -> (x,x)) 

instance Arrow a => GArrowSwap a (,) () where 
ga_swap = arr (\(x,y) -> (y,x)) 

instance Arrow a => GArrowConstant a (,) () t t 
where ga_constant x = arr (\() -> x) 

Figure 3. Instance declaration showing that every Arrow is a 
generalized arrow. This may be combined this with the instance 
declaration for Arrow (->) in Control. Arrow to provide an 
interpretation in Haskell for multi-level terms in languages which 
are a subset of Haskell. 



class, the GArrow class is a subclass of Category: every GArrow 
supports the id and >» operations, and obeys the laws (associativity 
and neutrality) required of any category. The GArrow class also has 
a ga_f irst function, whose type and laws are identical to those 
of the Arrow classrl although the accompanying "second" function 
(ga_second) does not have a default definition in terms of first. 

Unlike the Arrow class, the GArrow class has a second type param- 
eter ** of kind *—>•—>*, called the tensor of the generalized 
arrow. This plays a role for generalized arrows analogous to the role 
of pairing ( , ) in the Arrow class: using it, one may form binary 
trees whose leaves are types. Conceptually, one such tree is the type 
of the "input" and the other is the type of the "output." In contrast 
to the Arrow class, generalized arrows do not assume that this type 
operator is necessarily a cartesian product. Furthermore, allowing 
some type g to be an instance of GArrow via multiple different ten- 
sors will clarify the treatment of sums and products in Section [3,6, 1 1 
The third type parameter u, of kind •, plays the role of ( ) in Ar r ows ; 
it is called the unit of the generalized arrow. In the "trees of types" 
analogy above the unit type is the empty leaf. 

Note the conspicuous absence of the arr function for lifting ar- 
bitrary Haskell functions into the generalized arrow. In its place, 
we find six functions: ga_{un}cancel{l,r} and ga_{un}assoc. 
These are used to re-arrange the inputs and outputs of a generalized 
arrow: the ga_{un}cancel{l , r} functions add and remove super- 
fluous inputs and outputs (which must be of the unit type) whereas 
the ga_{un}assoc functions "re-parenthesize" the list of inputfTj 
Readers familiar with category theory will notice that this definition 
closely parallels that of premonoidal categories IPR97I . 

The GArrow class has three subclasses which are used quite fre- 
quently. GArrowCopy allows one to duplicate inputs, GArrowSwap 

3 One could argue that first belongs in a class BinoidalCategory, a 
superclass of Arrow. 

4 Why use binary trees instead of lists? One motivation is the desire to avoid 
having to prove facts about the associativity of list-concatenation at the level 
of types, something which cannot be done in the type systems of many 
languages. 
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allows one to change the order of inputs, and GArrowDrop allows 
one to delete inputs of arbitrary type by using ga_drop to turn 
them into inputs of the unit type which may then be discarded using 
ga_cancel{l ,r}. Note that the Arrow class does not permit this 
distinction: one can produce functions like ga_drop, ga_copy, and 
ga_swap for any Arrow instance by using the mandatory arr func- 
tion (the definitions appear in Figure[3](. Readers familiar with type 
theory and proof theory will notice that these definitions closely 
parallel the structural operations of ordered linear logic |Res09|. 

The three subclasses above frequently occur together; to reduce 
verbosity, the class GArrowSTKC collects them: 

class (GArrowDrop g (**) u, 

GArrowCopy g (**) u, 

GArrowSwap g (**) u) => 

GArrowSTKC g (**) u 

Instances of GArrowSTKC provide implementations of guest lan- 
guages which are supersets of the Simply Typed Kappa Calculus 
IHas95l . 

Conceptually, the nine functions ga_{un}cancel{l,r}, 
ga_{un}assoc, ga_drop, ga_copy, and ga_swap exist to "put 
back" what generalized arrows have lost - relative to the Arrow 
class - as a result of eschewing a mandatory arr. This can be made 
slightly more concrete by taking a look at the instance declaration 
in Figure [3] which gives every Arrow instance a canonical GArrow 
instance. This instance, in conjunction with the standard instance 
Arrow (->), may be used as an evaluation mechanism for guest 
languages which happen to be a subset of Haskell. The insertion of 
(sometimes quite a large number of) these re-arrangement function 
invocations is typically done by the compiler (see Remark [5. 1.1) . 
Programmers are responsible only for supplying the 
implementation for these re-arrangement functions. 

3.4 Example: BiGArrows 

We can now define the class BiGArrow, which avoids the problems 
of the BiArrow class by using generalized arrows in place of 
Arrows: 

class GArrow g (**) u => BiGArrow g (**) u where 
biga_arr : : (x -> y) -> (y -> x) -> g x y 
biga_inv : : g x y -> g y x 

The tutorial which accompanies the modified compiler includes an 
example BiGArrow instance which also implements class 
GArrowDrop using a logging translation |MHT04|. 

3.5 Multi-Level Terms and Types 



newtype Code x y = 
Code { unC : : for all a. 



<[ x -> y ]><3a } 



Haskell Arrows come with a very convenient syntax |Pat01 . Figure 
7], modeled on the monadic do-notation. Further work has been done 
on a calculus which types terms of the Arrow's internal language 
directly |LWY10|. Is there an equivalent for generalized arrows? 

There is. However, rather than being a custom syntax designed for a 
particular type class or category, it turns out than an existing syntax 
- which is in fact a typed calculus - is not only usable, but ideal. 
This calculus is the term syntax and type system of multi-level 
languages |NN92| augmented with environment classifiers |TN03|. 
This connection will be spelled out in formal detail in Section BJ 
here we give only the most cursory preview of multi-level terms, 
their types, and the connection. 

Multi-level terms involve two additional expression forms: brackets 
and escape. Brackets, written < [ . . . ] >, serve to demarcate an 
expression of the guest language. For example, the definition below 



instance Category Code where 
id = Code < [ \x -> x ] > 

f . g = Code <[ \x -> — (unC f) (~~(unC g) x) ]> 

instance GArrow Code (,) () where 
ga_first f = Code <[ \(x,y) -> ( — (unC f) x,y)]> 
ga_second f = Code <[ \(x,y) -> (x, — (unC f) y)]> 
ga_cancell = Code <[ \(_,x) -> x ]> 
ga_cancelr = Code <[ \(x,_) -> x ]> 
ga_uncancell = Code <[ \x -> (0,x) ]> 
ga_uncancelr = Code <[ \x -> (x,0) ]> 
ga_assoc = Code <[ \((x,y),z) -> (x,(y,z)) ]> 

ga_unassoc = Code <[ \(x,(y,z)) -> ((x,y),z) ]> 

instance GArrowDrop Code (,) () where 
ga_drop = Code < [ \_ -> u ] > 

instance GArrowCopy Code (,) () where 
ga_copy = Code <[ \x -> (x,x) ]> 

instance GArrowSwap Code (,) () where 
ga_swap = Code <[ \(x,y) -> (y,x) ]> 

Figure 4. Instance declaration showing that level 1 terms form a 
generalized arrow (at level 0). The newtype declaration is needed 
as a hint to the compiler's type inference mechanism. 



is the host language representation of a guest language's identity 
function: 

guest_id = <[ \x -> x ]> 

The escape form, written — e, serves to insert one guest language 
expression into another. For example, the definition below is the host 
language function which composes two guest language functions: 

guest_comp f g = <[ \x -> — f ( — g x) ]> 

Multi-level languages also introduce an additional type form: code 
types, written < [t] >@c for some type t and type variable c. Expres- 
sions wrapped in code brackets are given a type of this form, and 
expressions subject to the escape operator must bear a type of this 
form. This means that guest_comp above has the following type: 

guest_comp : : f orall c . 

<[y->z]>@c -> <[x->y]>@c -> <[x->z]>@c 

Note the additional type variable, c. This is an environment classifier 
|TN03|. In homogeneous multi-level programming, environment 
classifiers are used to ensure that certain terms of code type contain 
no free variables, and are therefore safe to execute. In heterogeneous 
metaprogramming an execution mechanism may or may not be 
available; even when it is unavailable these classifiers still serve an 
important purpose: a single host program might manipulate terms 
in multiple different guest languages; unification of environment 
classifier variables ensures that if one guest language term is pasted 
into another term (via the escape operator), the same guest language 
implementation (i.e., generalized arrow) is used to realize them. 

3.6 Multi-Level Terms to Generalized Arrows and Back 

As a preview of the connection between generalized arrows and 
multi-level languages, consider FigureH] which shows that level- 1 
terms may be used to implement the GArrow class (at level-0). This 
class instance is not typically used in practice - it is not involved in 
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pow n = 
if n==0 
then <[ \x -> 



1 ]> 



else <[ \x 

x 



f »» g = <[ \x -> ~~g (~~f x) ]> 
firstc f = <[ \(x,y) -> (~~f x,y) ]> 
secondc f = <[ \(x,y) -> (x, — f y) ]> 
mult :: <[ (Int.Int) -> Int ] >@a 



pow' n = 
if n==0 

then <[ \x -> 

<[ \() -> 

else < [ \x -> 



~(pow (n - 1)) 
]> 



]> 

1 ]> 
(x,x) ]> 

firstc <[ \x -> x ]> 
secondc (pow' (n-1)) 
mult 



»» 
»» 
»» 



pow 



pow 
if a= 
then 

else 



: : forall g (**) u. 
(GArrowConstant g (**) Int Int, 

GArrowSTLC g (**) , 

GArrowMult g (**) Int) => 

Int -> g Int Int 

n = 

ga_drop >» 

ga_constant 1 

ga_copy >» 

ga_first id >» 

ga_second (pow' (n-1)) >>> 
ga_mult 



Figure 5. The pow program from FigurefT] written three different ways. On the left, the original program, with spacing adjusted to imitate the 
following two programs (sadly the multiplication operator has no postfix form; ideally it should appear on the blank line). In the middle, the 
program has been rewritten in equivalent point-free form. On the right, code expressions have been replaced with identical definitions (modulo 
the newtype required as a hint to the compiler's type inference engine) from the GArrow Code instance of Figure[4] maintaining left-to-right 
order of expressions. Because no actual code terms appear in the third program, it is polymorphic in the GArrow instance and can be used with 
instances other than instance Code. 



the flattening process, nor do users typically rely on it. However, it is 
valid code (the modified compiler accepts it) and will help illustrate 
the flattening process. It provides one possible "translation back" 
from generalized arrows to multi-level terms. 

The formal definition of the flattening process is explained in 
complete detail in Section pi what follows is simply a sketch. 
Consider the pow program from FigurefT] 



pow n = if n==0 

then <[ \x -> 1 ]> 
else < [ \x -> x * - 



-(pow (n - 1)) x ]> 



One might imagine rewriting the program above in point-free form 
as shown in the middle column of FigureB] The rewritten program 
has a very important property: all expressions inside code brackets 
happen to occur in the GArrow Code instance of FigureH Because 
of this, we can replace these expressions with functions defined 
in the GArrow class; when instantiated with instance GArrow 
Code, the resulting program will be identical (modulo the newtype 
wrapper required as a hint to the compiler's instance inference 
mechanism) to the one above. This vague process is not the actual 
algorithm used to perform flattening, though it is based on the same 
idea. 



3.6.1 Beyond GArrowSTKC 

Generalized arrow instances which offer "constant values'' 
ment the class GArrowConstant below: 



imple- 



class GArrow g (**) u => 

GArrowConstant g (**) u 
ga_constant : : t -> g u r 



t r where 



The ga_constant function takes a value of type t and yields a 
generalized arrow whose input is the unit type u and whose result 
is type r. This return value is much like a Haskell function of type 
()->r. Note that t and r are not required to be the same type; a 
declaration instance GArrowConstant g (**) u t r asserts 
that the generalized arrow uses type r to represent constants whose 
type in Haskell is t. The "internal language" of the generalized arrow 
need not have all of Haskell's types, so one can expect that there may 
be some types g and r for which no GArrowConstant g _ _ _ r 
instance is possible. 



The benefits of separating Haskell's ( , ) from the generalized 
arrow's tensor can be seen in the GArrowSum class, which is roughly 
analogous to ArrowChoice |HugOO 5.1]: 

class (GArrow g (**) u, 

GArrow g (<+>) v) => 

GArrowSum g (**) u v (<+>) where 

ga_merge : : g (x<+>x) x 

ga_never : : g v x 

Note that g is required to be a generalized arrow via two separate 
tensors: the ** tensor is used for representing contexts, and the <+> 
tensor used to represent the sum of two types. The ga_f irst and 
ga_second functions on the <+> tensor give us the left and right 
of the ArrowChoice class, and the other functions of that class may 
be defined in terms of them. The ArrowChoice class fixes Either 
as the type operator used to represent sums, whereas GArrowSum 
leaves it abstract. For this reason we need ga_merge, which is akin 
to the obvious function of type Either a a -> a and ga_never, 
which produces a disjunct that "never" occurs. The left and right 
injections of the sum are given by: 



_inl 
inr 



j;a_uncancell »> 
j;a uncancelr »> 



.first ga_never 
.second ga_never 



Note how this example does not assume that the units of the two 
generalized arrow instances are the same. If this were the case, it 
would mean that the generalized arrow had a function similar to the 
Haskell function of type Va. () — > a. In Haskell the only function 
of this type is Xx.A. [Wad89|; total functional languages llTur041 
such as Coq have no functions of this type at all. Clearly the ability 
to separate the units of the two instances is important here. 

The class for products is defined dually: 

class (GArrow g (**) u, 

GArrow g (<*>) v) => 

GArrowProd g (**) u (<*>) v where 

ga_prod_copy : : g x (x<*>x) 

ga_prod_drop : : g x v 

There is an important symmetry here: the type of gajnerge is dual 
to ga_copy and the type of gajnever is dual to that of ga_drop. 
There are category-theoretic reasons for this: the unit of a coproduct 
is the initial object, while the unit of a product is the terminal 
object. Products have diagonal morphisms while coproducts have 
codiagonal morphisms. 
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In most cases, instances of GArrowProd will use the same type for 
both units u and v; this is because cartesian products let you "throw 
away" either coordinate, and languages without substructural types 
similarly let you "throw away" any element of the context (weaken- 
ing). One can add GArrow subclasses for type operators simulating 
the other connectives of linear logic |Pfe02| - additive conjunc- 
tion, additive disjunction, multiplicative conjunction, multiplicative 
disjunction - in a similar fashion; in these cases the units must 
be different. Another important example occurs in asynchronous 
dataflow, where a pair of streams is quite different from a stream of 
pairs - the latter has more stringent synchronization behavior. The 
inability to make this distinction forced the Fudgets library | CH93 ] 
to co-opt the coproduct structure of the underlying type system to 
represent pairs of streams, causing an anomoly that Paterson notes 
|Pat01 Section 5. 1] in the type of the Fudgets loop function. 



4. Foundations 

Having introduced generalized arrows in a cursory informal man- 
ner, these ideas will now be made rigorous. This section will make 
frequent use of finite binary trees whose leaves are either a distin- 
guished "empty" value or else of some particular sort S: 

Tree(S) = () | (5) | (Tree(S'), Tree(S)) 

This section will state results in terms of programming languages in 
general, though a few very basic assumptions are necessary. When 
speaking of a programming language £ we will assume that it has 
types, terms, and variables. We will assume that a context is a finite 
binary tree of types. We will assume some equivalence relation 
= on terms of the same type in the same context; typically this 
is a denotational semantics or contextual equivalence under some 
operational semantics, but those are not the only possibilities. We 
will assume some sort of syntactical substitution mechanism (let- 
binding, lambda-abstraction and application, explicit substitution, 
or some other mechanism) on terms which is associative up to = 
and for which the identity terms are left and right neutral. We will 
assume that the language comes with some collection of inference 
rules such that for every term e which has type r in context Y there 
is a natural deduction proof with conclusion Y h (r) and no open 
hypotheses and, and furthermore that e can be recovered from this 
proof. 

4.1 The Category Types(£) 

For a particular programming language £ (e.g., Haskell), there 
is a well-established way to produce a category. Following the 
unfortunate convention that categories are named after their objects 
(Cat, Grp, Sets) rather than their morphisms, we have: 

Formalized Definition 4.1.1 (TypesL) Let £ be a programming 
language. Types (£) is the following category. Objects: finite binary 
trees with a type of £ at each nonempty leaf. Morphisms from A 
to B: a binary tree T of the same shape as B, where each leaf of T 
is a term which has the type at the corresponding leaf of B in the 
context consisting of all the leaves of A. Equality of morphisms: a 
pair of morphisms f,g:A—>B are equal if their constituent terms 
are pairwise (=)-equivalent. 

Formalized Theorem 4.1.2 (TypesL_PreMonoidal) Types(£) 
is a premonoidal category, where the functor — x B sends an object 
A to {A, B) and a morphism / : A — > C to (/, ids) and the functor 
A xi — sends an object B to {A, B) and a morphism f : B — > C to 
<i<U,/>. 



This category is not strict premonoidal. Its strictification ILan71l 
Theorem XI.3.1] - a category in which the objects are lists of types 
rather than binary trees - is more common in the literature, but 



removes some structure we will need later on. Perhaps the earliest 
example comes from Lawvere's thesis |Law63|, later revisited as 
|Law96l , explaining quantifiers as adjunctions, which led to the 
general concept being called a Lawvere Theory. More verbosely, 
Types(£) could be called "the non-strict multi-sorted Lawvere 
Theory of the term algebra of £". In the context of logic, Awodey 
refers to this as the formula category |Awo06, 9.5]. Crole refers to it 
as the classifying category of a theory |Cro94 4.8.4]. Other names 
include "clone category" |Ber98 Definition 8.9.4] and "category of 
derived operations of an algebra." The full subcategory of Types(£) 
consisting of only those objects which have exactly one leaf is often 
called the Lindenbaum category of an algebra (in this case, the 
term algebra), and in the case of the language Haskell this is the 
category most frequently referred to as "Hask." Types(£) occurs in 
non-strictified form as a special case of far more general work by 
Blute, Cockett, and Seely IBCS97I . 

4.2 The Category Judgments (£ ) 

Having defined the category of types of a language, we now move 
to a second category: its category of judgments. Let a context be a 
binary tree of types (i.e. an object of Types(£)) and let a judgment 
be a pair of contexts, written Ti h JT^, 

Formalized Definition 4.2.1 (JudgmentsL) Let Judgments(£) 
be the following category. Objects: finite binary trees with a 
judgment at each non-empty leaf. Morphisms from A to B: a binary 
tree T of the same shape as B, where each leaf of T is a proof having 
all the leaves of A as its hypotheses and the corresponding leaf of 
B as its conclusion. Equality of morphisms: a pair of morphisms 
f,g : A —> B are equal if the expressions recovered from the 
conclusions of their constituent proofs are (=)-equivalent. 

Observe that we allow a context (tree of types) rather than merely 
a single type as the succedent of a judgment. In contrast to natural 
deduction for classical logic, these trees are conjunctive rather than 
disjunctive: a proof of Y h (n , T2) establishes the well-typedness 
of both n and T2 ■ 

Like Types(£), this category can be found elsewhere in the literature, 
under many names: its use in the study of programming languages 
and type systems originated with Cartmell |Car86, Section 13], 
who calls this the "category of contexts and relations" R(U) for a 
term category U and explains how to construct it for cases where 
the base category has all finite limits (though Types(Haskell) does 
not) and certain projection morphisms exist - roughly equivalent to 
assuming that the unit object is terminal. Lambek |Lam69j p79] 
calls this the deductive system on a category (in this case, the 
category Types(£)). Szabo |Sza78 1.1.26,2.5.3] calls it a sequential 
category generated by an unlabeled deductive system (i.e., category 
of sequents). Szabo's work also demonstrates that Types(£) (which 
he calls Fm(X)) is isomorphic to a subcategory of this category via 
the covariant hom-functor embedding. This last result is the closest 
thing to Theorem |4.3.1| we have been able to find in the literature. 

Formalized Definition 4.2.2 (Judgments_cartesian) 
Judgments (£) is a cartesian category. 

4.3 Relating Judgments(£) and Types(£) 

Of great importance to the rest of the development is the relationship 
between Types (£) and Judgments (£): 

Formalized Theorem 4.3.1 (TypesEnrichedlnJudgments) 
Types(£) is enriched |Kel82, 1.3] in Judgments(£). 

Formalized Definition 4.3.2 (Types_f irst, Types_second) 
The functors — x A and A x — which give Types(£) its 
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premonoidal structure are Judgments(C)-enriched functors |Kel82 
1.10]. 

The following simple definition will be helpful: 

Formalized Definition 4.3.3 (Enrichment) An enrichment, 

written C € V, is a monoidal category (V, ©,/„} and a 
premonoidal category (C, K, X , I) such that C is the underlying 
category of some V-enriched category, and all of the functors 
A x — and — xi A are V-enriched functors. 

Enriched categories are defined in only those categories which are 
monoidal, so the monoidal structure of V is a necessary part of 
this definition. Asking that C be premonoidal and including the 
"extra structure" which makes it so as part of the enrichment will 
simplify later definitions. Lastly, recall the definition of the center of 
a premonoidal category and the fact that it is a monoidal category: 

Formalized Definition 4.3.4 (Center) For C a premonoidal 
category, the center of ' C, written Z(C), is the collection of all 
central morphisms of C 

Formalized Lemma 4.3.5 (CenterMonoidal) For C a pre- 
monoidal category, Z(C) is a monoidal subcategory of C 

4.4 An Arrow in C 



Formalized Definition 4.5.3 (GeneralizedArrow) For enrich- 
ments K € Vk and C € V, a generalized arrow from K € Vk to 
C € V is a monoidal functor from Vk to Z(C). 




Z(C) 



Formalized Theorem 4.5.4 (ArrowsAreGeneralizedArrows) 
If J:Types(C) — > Z(K) is an Arrow in programming language C, 
the inclusion functor from the enriching category of K. to Types(£) 
is a generalized arrow from Z(K) € Vk to 
Types(£) € Judgments (£): 




Judgments (£) 



Z(K) 



Types(£) = Z(Types(£)) 



Within this framework of languages-as-categories, what is an in- 
stance of the Arrow class? 

Formalized Definition 4.4.1 (FreydCategory) A Freyd 
Category] PT97 1 [PT99 1 is an identity-on-objects strict symmetric 
monoidal functor J-JC — > Z(¥L) where C is a cartesian category 
and K (called the Kleisli category) is symmetric premonoidal. 

Formalized Definition 4.4.2 (ArrowInProgrammingLanguage) 
An Arrow in a programming language C with Types(£) cartesian is 
an enrichment K € Vk with Vk C Types(£) and a Freyd Category 
,7:Typesf£) -> Z(K) IAtk08l Theorem 3.71. 

For example, in Haskell any particular instance Arrow T deter- 
mines a full subcategory of Types(Haskell) consisting of types of 
the form T X Y for any X and Y. The Kleisli category K of the 
Arrow is enriched in this subcategory of Types(Haskell). 

4.5 Generalized Arrows 

We are now ready to define a generalized arrow in a programming 
language: 

Formalized Definition 4.5.1 (GeneralizedArrowInLanguage) 
For programming languages Q and H, a generalized arrow from 
language Q to language H. is a monoidal functor from Judgments(CJ) 
to Z(Types("H)). 



Judgments(5) 



Judgments (H) 



W 



Types(5) 




Z(Jypes(H)) 



Remark 4.5.2 Note that the domain of the functor is a judgment 
category whereas its codomain is [the center of] a term category; in 
this sense, generalized arrows represent the proof structure of one 
language within the term structure of another language. 

We can expand the scope of this definition to arbitrary enrichments: 



Note that Types(£) = Z(Types(£)) because the domain of a Freyd 
Category must be cartesian (all morphisms are central). 

Remark 4.5.5 Often, given an Arrow J in a programming 
language as above, one can cook up a language C, such that 
Z(K) = Types (£ ) and Va' — Judgments (£ ), making the result 
of Theore m|4,5.4| not just a generalized arrow between enrichments 
(Definition|4.5.3|> but also a generalized arrow between languages 



C A and C (Definition 4.5.1 1 



Remark 4.5.6 A great deal of work has been devoted to iso- 
lating the right definition of an Arrow in an arbitrary category 
IJHI09 JH06 HJ06, Atk08l lAsaT0l lAH10i. such that Arrows in 
programming languages occur as a special case. These Arrows- 
in-arbitrary-categories are outside the scope of the present paper; 
focus here is limited to those Arrows which occur in a programming 
languages. For example, Arrows on the category of sets or on the 
category of vector spaces are not considered. 

4.6 Multi-Level Languages 

Having defined generalized arrows, we now turn to multi-level lan- 
guages. First, however, a definition in terms of arbitrary enrichments: 



Given two enrich- 

V K to C € V is a 



Formalized Definition 4.6.1 (Reif ication) 

ments K € Vk and C € V, a reification from 1 
monoidal functor TZ : Vk — > V such that for every A"G06(K) there 
exists a functor 3# : K — ¥ Z(C) making the following diagram 
commute up to natural isomorphism: 

Vk ® > V 



3/c 



With this definition in place, the definition of a two-level language 
is straightforward: 
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Formalized Definition 4.6.2 (TwoLevelLanguage) A 

two-level language (Q, H) consists of a pair of languages Q and H 
and a reification from Types(iJ) € Judgments(<5) to 
Types(H) € Judgments('H). 



Judgments((5) 



R 
-©- 



Judgments (H) 



Types(£) 



Z(Types(H)) 



Remark 4.6.3 The essence of a multi-level language is a functor 
from one Judgments category to another; in this sense, multi- 
level languages represent the proof structure of one language 
within the proof structure of another language. Compare this with 
Remark l4JT2l 

The motivation for this definition can be found in literature all the 
way back to the earliest work on typed multi-level languages. In 
|NN92 p39] the authors "sketch the form of the general construction 
[of a two-level language] . For each well-formedlness rule or axiom R 
for types in L, and each binding time b£B, we add the rule or axiom 
R b ;" their specification for R b - translated into the terminology of 
category theory - forms the functor 1Z above when the host language 
has function types =>■ for which Hom(X, Y) = Hom(J, X=>YFJ 

Remark 4.6.4 Note that the functors TZ and 3k are not necessar- 
ily full or faithful. This will be revisited in Section[6] 

By iterating and taking limits, we arrive at n-level languages and 
oj-level languages: 

Formalized Definition 4.6.5 (NLevelLanguage) Every lan- 
guage is a one-level language. An (n + 1) -level language is a 
two-level language (C n , C) where C n is an n-level language. 

Formalized Definition 4.6.6 (DmegaLevelLanguage) An ui- 
level language is a function / whose domain is the natural numbers 
such that (f(n), /(n+1)) is a two-level language for every n G N. 

4.7 Multi-Level Languages are Generalized Arrows 

Although Types(£) € Judgments(£) gives an enrichment for any 
programming language, not all enrichments arise this way. The next 
three properties hold for all enrichments which do arise this way 
(Lemma [4.7.5[ ) from languages with cartesian product types. They 
capture the formal facts needed to drive the remainder of the proof. 

Formalized Definition 4.7.1 (MonicEnrichment) An enrich- 
ment C € V is monic if there is an object X such that hom(A, — ) : 
C -¥ V is faithful. 

The enrichment of any concrete category in Sets is monic. Intuitively, 
to say that an enrichment is monic is to say that its base category C 
is "concrete with respect to" V (rather than Sets). Often X is called 
a generator for C The enriched category of a monic enrichment is 
called well-pointed if X is a terminal object. 

Formalized Definition 4.7.2 (SurjectiveEnrichment) An 
enrichment C € V is surjective if every object of V is the tensor of 



5 This was the case for all of the systems considered in | NN92 1, and is also 
for all typed A-calculi. The definition given here - without reference to 
function types - may be used to define multi-level languages in which the 
host language does not have such function types (for example, languages 
based on K-calculus). 



finitely many objects each of which is either the unit object I v of V 
or a hom-object of C 

Intuitively, surjective enrichments are those in which the enriching 
category has no extraneous objects unnecessary to the enrichment 
(note that this says nothing about morphisms). This is not a seri- 
ous limitation; one can simply restrict the focus to the least full 
subcategory in which C is enriched. 



Formalized Definition 4.7.3 (MonoidalEnrichment) 
richment C € V is monoidal if hom(7, — ) : Z(C) - 
monoidal functor. 



An en- 



Intuitively, a monoidal enrichment is one in which the base cate- 
gory's tensor is "rich enough" to represent the structure of its own 
judgments. The most common case is: 

Formalized Theorem 4.7.4 (CartesianEnrMonoidal) Any 
enrichment C € V with both C and V cartesian is a monoidal 
enrichment. 

Formalized Lemma 4.7.5 (LanguagesWithProductsAreSMME) 
If a programming language £. has cartesian contexts (i.e., 
weakening, exchange, and contraction) (i.e. pairs), then 
Types(£) € Judgments(£) is a surjective monic monoidal 
enrichment. 

In a vague sense, surjective monic monoidal enrichments "look 
enough like programming languages" for the proof to go through. 

Formalized Definition 4.7.6 (CategoryOfReif ications) 
The category of reifications is the category with Objects: surjective 
monic monoidal enrichments, Morphisms from E\ to E2: 
reifications from E\ to E2, Equality of morphisms: reifications 
whose TZ functors are naturally isomorphic. 

Formalized Definition 4.7.7 (CategoryOf GeneralizedArrows) 
The category of generalized arrows is the category with Objects: 
surjective monic monoidal enrichments, Morphisms from E\ to 
E%: generalized arrows from E\ to E%, Equality of morphisms: 
generalized arrows which are naturally isomorphic as functors. 
Composition of two generalized arrows A : E2 — ¥ E3 and 
A' : Ei — > E2 is given by A o hom.E 2 (J, — ) o A'. 

This leads to the main technical result of the paper: 

Formalized Theorem 4.7.8 (Reif icationsAreGArrows) The 
category of reifications is isomorphic to the category of generalized 
arrows. 

In intuitive terms, the proof of isomorphism of categories re- 
quires a (identity-preserving, composition-respecting) mapping 
Mi from generalized arrows to reifications, a (identity-preserving, 
composition-respecting) mapping A/2 from reifications to general- 
ized arrows, and proofs that Mi(M2(TZ)) is naturally isomorphic 
to 1Z and M2{M\{A)) is naturally isomorphic to A. Coming up 
with M\ and M2 is, of course, the hard part. For Mi we simply pre- 
compose the generalized arrow functor with the hom(7, — ) functor 
on its codomain. Finding its companion, M2, is more difficult: its 
construction relies on the fact that, because the domain of the reifi- 
cation functor 1Z is part of a surjective enrichment, we can reason 
by induction on trees of hom-objects. The base case relies on the 
fact that the reification functor forms a commuting square with 
hom(7, — ) (via 3k) for every hom(K, — ), and the inductive step 
exploits the fact that the codomain enrichment is monoidal, allow- 
ing us to "represent" trees of objects. Together these provide an 
isomorphism between the range of 1Z as a subcategory and the base 
category of its codomain; this isomorphism may be post-composed 
with the reification to produce a generalized arrow. The Coq proof 
is normative; this is only a sketch. 
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Definition 4.7.9 For TL a reification functor, we will write TZ for 
M 2 (ft) and .4 for Mi (.4) = hom(7, -) o A 

Remark 4.7.10 The definitions above require that all objects of 
the category of generalized arrows and of the category of reifications 
be surjective monic monoidal enrichments. This is somewhat more 
restrictive than necessary: the same result holds when the category 
has as its objects all enrichments, but no morphisms E\ — > E-z 
unless E\ is surjective and E2 is monic monoidal. This allows for 
guest languages whose enrichments are not monoidal. 

The process of calculating TZ is loosely analogous to the creation 
of the instance in Figure Ul Using TZ to flatten a multi-level term 
- loosely analogous to the translation from the left column of 
Figure [5] to the center column - involves walking over a proof in 
Judgments('H) replacing morphisms in the range of TZ (i.e. proofs 
of well-typedness of terms in code-brackets) with the action of TZ 
on their preimage under 1Z. The final step in Figure [5] (from the 
center column to the right hand column) takes advantage of type 
classes, a feature which is not in every host language. This final step 
is host-language-specific, and its formal counterpart is the topic of 
the next section. 



4.8 Flattening 

Formalized Definition 4.8.1 (FlatSubCategory) Given a two- 
level language (Q, Ti) with reification functor TZ, the full subcate- 
gory of Types(H) consisting of all objects X such that Horn (7, X) 
is not in the range of 1Z is the flat subcategory Flat(5, Ti) of the 
two-level language. 

Formalized Definition 4.8.2 (RetractionOfCategories) A 
retraction of categories (J-,J-') : A C. B is a pair of functors 
T : A -»• B and T' : B -5> A such that T' o T is naturally 
isomorphic to id^ : A — > A. 

Formalized Definition 4.8.3 (FlatteningOfReif ication) 
Let (Q, Ti) be a two-level language with reification functor TZ. If 
there exists a retraction (F, J 7 ') : Ran(ft) C Flat(<3, Ti) from the 
range of 1Z to the flat subcategory of Types(H), then let T o 1Z be 
the flattening of 7?.. 



Judgments(<3) 




Judgments (Ti) 



Z(Types(H)) 



Types(C;) — -> Ran(ft) — * Flat(G,H) 



It is immediate that the range of the flattening of a reification falls 
within the flat subcategory of its codomain, since it arises by post- 
composing with the retraction. The proof that a retraction T exists 
is typically language-specific; the following section addresses the 
case for Haskell. The flattening process preserves all information 
present in the original reification in the following sense: 

Formalized Lemma 4.8.4 (FlatteninglsNotDestructive) 
Post-composing the flattening of a reification with 
hom(7, — ) o T~ x gives back the original reification functor. 



5. Proof of Concept 

To demonstrate the feasibility of these ideas, a modified version of 
the Glasgow Haskell Compiler (GHC) |Tea09| has been created. 
This modified GHC offers a new flag, -XModalTypes, which adds 
new expression syntax for code brackets and escape, new type 
syntax for code types (with environment classifiers), inference 
of environment classifiers using GHC's existing arbitrary-rank- 
polymorphism type inference engine |Dim05 1, and an expansion of 
the type checker to include the additional typing rules described in 
this section. 

This paper's accompanying Coq s cript includes a complete for- 
malization of System FC" (Section [5,lfr , a reification from a sim- 
ple PCF-like language to System FC", and a flattening functor 
for this reification. The Coq code is extracted to Haskell code, 
which is then compiled in to the compiler, providing a new flag 
-f coqpass which invokes the flattening transformation. A library 
GHC . HetMet . GArrow is also provided; it includes known-to-the- 
compiler type classes for generalized arrows. 

5.1 System FC" 



GHC uses System FC |SCJD07 post-publication Appendix C] 
as its intermediate language (as of this writing GHC has not yet 
been updated to use System FC 2 | WVJZ1 1 1). This language is rich 
enough to capture the type structure of Haskell as well as the large 
variety of extensions supported by GHC. System FC" is little more 
than the union of the grammars and typing rules of System FC and 
A" |TN03 1. The remainder of this section explains the modifications 
made to harmonize the two systems and ensure that its proofs form 
a category Judgments(System FC"). System FC" is of little direct 
interest as a type system on its own; it is defined only in order to 
facilitate the implementation and avoids deviating from the naive 
union of System FC and A" except where absolutely necessary. 
Those deviations are: 

1. Inference rules for annotations (Note), recursive let bindings 
(LetRec), and literals (Lit) have been added because these 
constructs appear in GHC's CoreSyn but not in |SCJDQ7| post- 
publication Appendix C]. 

2. The Alt rule of System FC has been inlined into the Case rule 
in order to have only a single sort of judgment on expressions. 

3 . The environments for kinding of type variables (T), classification 
of coercion variables (A), and typing of value variables (E) are 
kept separate. 

4. The branches of a case statement, letrec bindings, and the 
environment assigning types to value variables are represented 
using binary trees and explicit structural manipulations rather 
than lists and variable names. Because of this, expressions need 
not appear in judgments - the expression whose well-typedness 
is witnessed by a proof can be reconstructed, up to a-renaming, 
from the structure of the proof itself. The auxiliary judgment 
Ei ~~+ E2 asserts that the context E2 may be produced from Ei 
by invocation of structural operations. 

5. Rather than represent contexts as type-variable pairs with an 
auxiliary variable-level map a as in |TN03 1, contexts are repre- 
sented as (trees of) type-level pairs with no auxiliary map. 

6. Rather than decorate each judgment with a named level, the 
succedent of the judgment is decorated. 

Remark 5.1.1 The rules for Var and Lit require that the context 
contain no extraneous entries; this forces the proof-builder to invoke 
the Weak rule in order to get rid of these entries. Because the flat- 
tening functor sends the Weak rule to the ga_drop function, this 
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Figure 6. System FC a , the union of System FC and \ a along with the changes enumerated in Sectionpj] The grammar for coercions 7 
and patterns p and the rules for the type-well-formedness judgment Fty and coercion-well-formedness judgment hco are identical to those of 
System FC and are not shown; they may be found in [SCJD07 post-publication Appendix C]. 



requirement is essential to ensuring that the result of the flattening 
process is well-formed (and well-typed). Similarly, the App, Let, 
Case, and LetRec rules require that the conclusion context be "parti- 
tioned" amongst the hypotheses (Cont/ga_copy) in the correct order 
(Exch/ga_swap); reconstructing this partitioning from a CoreSyn 
expression accounts for a significant portion of the complexity in 
the Coq development, but it is the "engine" of the flattening trans- 
formation and it is here that the compiler does the work of piecing 
together ga_swap, ga_copy, ga_drop, ga_{un}cancel{l,r}, and 
ga_{un}assoc - the work which makes generalized arrow instances 
so tedious to use without help from the compiler. 



A few conservative restrictions have been imposed in places where 
there was uncertainty about the interaction between levels and 
features of System FC; these may be loosened in the future: the 
variables bound by a letrec must have the same named level, literals 
may appear only at level zero (the compiler comes with special 
functions to transport literals from level zero to positive levels) 
and the following expressions may occur only at level zero: the 



cast expression, coercion lambda, coercion application, and case 
expressions which bind coercion variables. 



Formalized Definition 5.1.2 (SystemFCa) 
programming language of Figure[6] 



System FC a is the 



Formalized Definition 5.1.3 (PCF) PCF is the sublanguage of 
System FC a consisting of proofs which do not use the following 
rules: Case, Cast, AbsT, AppT, AbsC, AppC. This is roughly 
equivalent to the Programming Language for Computable Functions 
IPlo77l without integers or booleans. 



Formalized Theorem 5.1.4 (PCF_SystemFCa_two_level) 
(PCF, System FC a ) is a two-level language for which the the 
retraction of Definition l4.8.3l exists. 
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Judgments(PCF 



R 



Judgments (System FC") 

T 




Types (System FC° 



Types (PCF 



The functor 3 K : Types(PCF) — > Types(System FC a ) above sends 
/ : X -> Y in Types(PCF) to 

3 K (/) : forall c. < [K -> X]>@c -> < [K -> Y] >@c 

in Types(System FC a ), and the retraction T sends this to 

J"(3 K (/)) : forall c. GArrowPCF c=>cKX->cKY 

6. Conclusion and Future Work 

Why heterogeneous metaprogramming? The effort expended in 
this paper is largely unnecessary if we are content with guest 
languages which are the same as - or even supersets of - the host 
language. The simplest "naturally occurring" example is that of 
invertible programming, as shown in the running BiArrow example 
of Section |372| An invertible programming language cannot include 
all of Haskell, since Haskell has functions which are quite obviously 
not invertible (e.g. f st). 

Beyond applications like BiArrow which fit in a paragraph or two 
lie more appealing examples, includ ing the de sign of digital circuits 
(much like Lava [BCSS98 SJRI0Tl lGBK + 09h . stream processing 
of trees |KSK08| based on ordered linear types, and NESL-like 
data parallelism on platforms without global shared memory where 
(unlike |CLJ07|) parallelized functionals do not have access to the 
heap (i.e., they are access-restricted |Ble95. 10.3]). 

6.1 Deficiencies 

Due to space limitations, the generalized arrow analogs of 
ArrowLoop (GArrowLoop), ArrowApply (GArrowApply, 
GArrowCurry), multi-stage run (GArrowEval, GArrowRef lect), 
and arr (GArrowReif y) are not described in this paper. They may 
be found in the modified base library, in 
GHC/HetMet/GArrow.hs. The flattening of rule (LetRec) uses the 
ga_loopr and ga_loopl definitions of GArrowLoop; also used are 
ga_curry{l,r} and ga_apply{l,r} from GArrowCurry and 
GArrowApply, respectively. GArrowLoop, GArrowCurry, and 
GArrowApply are all superclasses of GArrowPCF. 

Although the equivalence of generalized arrows with multi-level 
languages has been proved in general form as an isomorphism of 
categories, the flattening lemma relies on the existence of a retraction 
in the host language. At the moment no necessary-and-sufficient 
condition is known for the existence of this retraction. This does not 
impact the soundness of this paper's results, but adds an undesirable 
extra proof burden to be taken on each time the flattening lemma 
and corresponding transformation are to be applied to a new pair 
of guest/host languages. A simple property "P" and proof which 
works for any pair of guest/host language having property P would 
be more desirable. The most likely candidate is some variation on 
"Q is the domain of the initial object of the slice category over 7-L." 



Although the current proof scripts establish that there is a reifi- 
cation from PCF to System FC", the actual functor used in the 
-f coqpass extraction is constructed directly, rather than by invok- 
ing Theorem |4.7.8| and post-composing the resulting functor with a 
retraction. 



6.2 Future Work 

A number of interesting classes of Arrows arise by requiring that 
the hom-sets of the Kleisli category of the Arrow each carry some 
sort of additional structure. For example, the ArrowPlus class 
assumes that for each pair of types x and y, if a is an instance 
of ArrowPlus, then the values of a x y form a monoid, with the 
zeroArrow and <+> methods of ArrowPlus as the identity element 
and multiplication operator. Arrows with semiring, ring, lattice, 
boolean algebra, relation algebra, and Kleene algebra structures 
on their homsets are also possible; the last is particularly useful 
for concurrency. Even the structure of a category on the homset is 
possible, making the Arrow's Kleisli category K a 2-category. All 
of these possibilities carry over directly to generalized arrows; the 
question of what the corresponding multi-level language features 
are has yet to be answered. 

The fact that the proofs above work even for reifications whose 
functors are not full or not faithful (Remark |4.6.4| suggests other 
interesting directions. A non-faithful reification functor would 
suggest a guest language with a finer equivalence relation on 
terms than its host language; for example, a guest language with a 
syntactical notion of equality and a host language in which equality 
is considered modulo a-equivalence. A non-full reification functor 
suggests a host language which has functions between the images 
of guest types which, nonetheless, are not themselves the images of 
guest functions. 

In the present implementation it is not possible to determine, 
solely from the type of a multi-level term, which of GArrowDrop, 
GArrowSwap, GArrowCopy must be implemented in the generalized 
arrow supplied to the flattened version of the term. In order to do 
so, one must track the dereliction, reordering, and duplication of 
variables in the types of the source language; GHC currently does 
not have support for this. 
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